import { Link } from '@brillout/docpress'

Vike differs from Next.js in three fundamental ways:
 1. Vike is agnostic to <Link href="#deployment-hosting" doNotInferSectionTitle />.
 1. Vike is full-fledged yet <Link href="#minimal-and-self-contained-no-deps" doNotInferSectionTitle />.
 1. Vike is <Link href="#ui-framework-agnostic" doNotInferSectionTitle />.

Beyond these structural differences,
Vike introduces features such as blazing fast HMR (powered by Vite), optional SSR, Domain-driven File Structure, state-of-the-art Code Splitting (powered by Vite/Rollup), Automatic Deployment Synchronization, <Link href="#build-your-own-framework" doNotInferSectionTitle />, etc.

> Turbopack replicates some of Vite's techniques, but it's still in its infancy and it will take a while until Turbopack is production-ready. With Vite, you can use lightning fast DX today.

Finally, Vike is a community project: instead of leaning on a framework with business interests that are fundamentally at odds with yours, use a community-driven project that is sponsored by, made for, and made by the community.



## Detailed comparison table

[From @patryk-smc and @redbar0n](https://github.com/vikejs/vike/issues/158#issuecomment-1250068578):

|                                                                 | Vike                                                       | Next.js                       |
| --------------------------------------------------------------- | ---------------------------------------------------------- | ----------------------------- |
| Bundler                                                         | Vite (dev: esbuild+ESM, prod: Rollup)                      | Webpack                       |     
| UI Framework                                                    | Any (React, Preact, Solid, etc.)                           | React only                    |
| Code-splitting and bundling                                     | Yes                                                        | Yes                           |
| HMR                                                             | Yes, fast                                                  | Yes, slow                     |
| Optional SSR                                                    | Yes                                                        | Limited (app[[1]](https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b333434ef6?permalink_comment_id=4508093#gistcomment-4508093), pages[[2]](https://nextjs.org/docs/app/building-your-application/deploying/static-exports#unsupported-features)[[3]](https://github.com/vercel/next.js/issues/54393), components[[4]](https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading#skipping-ssr)[[5]](https://www.npmjs.com/package/react-no-ssr))                            |
| <p align="center">**SSR**</p>                                   |                                                            |                               |
| Control                                                         | Full control                                               | Limited / Black box                      |
| Renderers                                                       | Yes, create as many you need                               | Just one (`_app.ts` file)      |
| RSC (React Server Components)                                   | Yes, <Link href="/react#react-server-components">partially</Link> | Yes, experimental       |
| <p align="center">**Routing**</p>                                                        |                                                            |                               |
| Filesystem Routing                                              | Yes                                                        | Yes                           |
| <Link text="Domain-driven Filesystem Routing" href="/file-structure#domain-driven" />                                        | Yes                                                        | No                            |
| <Link text="Client Routing" href="/client-routing" />           | Yes                                                        | Yes, but [limited](https://github.com/vercel/next.js/discussions/64660) in SPA-only mode ***                           |
| <Link text="Server Routing" href="/server-routing" />           | Yes                                                        | No                            |
| <Link text="Base URL" href="/base-url" />                       | Yes                                                        | Limited                       |
| <p align="center">**Pre-rendering (SSG)**</p>                                                   |                                                            |                               |
| Pre-rendering (SSG)                                    | Yes, for pages                                                        | Yes, for pages, or components ([Partial Pre-rendering](https://nextjs.org/learn/dashboard-app/partial-prerendering) using RSC)                               |
| Incremental Static Regeneration (ISR)                  | No*, use <Link text="vite-plugin-vercel" href="/vercel#vite-plugin-vercel" />        | Yes, in the Node.js runtime, on Vercel    |
| SPA-only mode (popular for PWAs) ***                   | Yes                                                        | Limited: [no dynamic routing in App Router](https://github.com/vercel/next.js/discussions/64660)                       |
| <p align="center">**Integrations**</p>                                                    |                                                            |                               |
HTTP server | No*, bring your own | Baked-in, custom server partially supported with caveats[[1]](https://github.com/vikejs/vike/issues/158#issuecomment-1355306156)[[2]](https://stackoverflow.com/questions/58742343/do-i-have-to-use-express-in-next-js-project/70945468#70945468) |
| Apollo Client with SSR                                          | Fully supported                                            | Partially supported           |
| Relay with SSR                                                  | Fully supported                                            | Partially supported           |
| <p align="center">**Extras**</p>                                |                                                            |                               |
| Head component                                                  | No*, use a tool like [react-helmet](https://github.com/nfl/react-helmet). | Yes, next/head                |
| Image component                                                 | No*, use an <Link href="/img">image optimizer tool</Link>. | Yes, next/image               |
| API routes                                                      | No*, use your server or an <Link text="RPC tool" href="/api-routes" />.   | Yes                           |
| Internationalization (i18n)                                     | Yes                                                         | Limited                       |
| <Link href="/deploy-sync" />                                    | Yes                                                         | No                            |
| [Build your own framework](https://vike.land)                   | Yes                                                         | No                            |
| <p align="center">**Deployment options**</p>                                              |                                                            |                               |
| Vercel                                                          | Yes, minimal config                                        | Yes, zero config              |
| Cloudflare Workers                                              | Yes, minimal config                                        | Yes, but limited              |
| Node server (Docker, Heroku, Digital Ocean etc.)                | Yes, minimal config                                        | Yes, but limited              |
| Caching (see own section above)                                 | No*, if needed, use industry-standard caching**.           | App Router [caching](https://nextjs.org/docs/app/building-your-application/caching), [opt-out](https://www.reddit.com/r/nextjs/comments/15wc4nt/nextjs_caching_opt_out/)   |


(\*) Vike doesn't ship those extras by design.

(\**) Industry-standard ways of caching is to use the HTTP Cache-Control header to [cache in the client's browser](https://web.dev/articles/http-cache) and potentially also on a shared/public [CDN](https://www.cloudflare.com/lp/ppc/cdn-x/) cache in front of your server side. Additionally, if you ever need even more caching than that, it's possible to have an in-memory cache on your server-side using e.g. [Redis](https://developer.redis.com/howtos/solutions/microservices/caching/) or Memcached.

(\***) SPA-only mode means you make a static export of your app, into HTML, CSS and JS files, and serve them from a CDN, which means you don't need any server compute on requests (as opposed to SSR).



## User feedback

[From @Axxxx0n](https://github.com/vikejs/vike/issues/158#issuecomment-934224512):

1. Blazing fast development speed powered by Vite (on-demand transpiling, native ESM).
1. Next.js has to have many examples and a whole plethora of libraries are existing just to integrate some library with Next.js because it's not trivial (for example [next-i18next](https://github.com/isaachinman/next-i18next)). With Vike, you just read the documentation of the library you want to integrate and you're good to go.
1. When new React features arrive you can start to use it right away and don't have to wait for the Next.js team to integrate it. (Streaming API, server components, suspense on server, progressive rendering, etc.)
1. Next.js can't read files in `/public` directory after it was built, i.e. user uploaded images.
1. With `getServerSideProps()`, Next.js blocks client-side rendering.
1. You cannot bypass data fetching on client-side navigation ([Next.js - 	&#35;23921](https://github.com/vercel/next.js/discussions/23921)) while with Vike you're flexible and can choose what you want.
1. Next.js is really pushing the Vercel platform and is starting to show in recent feature updates. Features that align with this are getting priority while important fixes are delayed.
1. Next.js is leaning on serverless and complicates usage when you don't want it.



## Deployment / hosting

### Next.js - optimised for Vercel

Next.js is made by [Vercel](https://vercel.com), a hosting provider. It is therefore naturally optimised to run in their environment and infrastructure. But Vercel
is
[known](https://eightify.app/summary/web-development/the-shift-from-vercel-to-aws-amplify-cost-and-scaling-benefits)
to
[become](https://www.reddit.com/r/nextjs/comments/12t5nhi/needed_alternatives_for_vercel/)
very
[expensive](https://x.com/zackerydev/status/1717556827569660378)
at
[scale](https://www.reddit.com/r/nextjs/comments/q7vw6p/cheaper_vercel_alternatives_specifically_to/hgm7d1t/).
What's worse is that [Vercel's pricing](https://vercel.com/pricing) is
misleading (the pay-per-developer make it seem cheap but you usually pay for very expensive fees for exceeding limits),
[opaque](https://www.reddit.com/r/nextjs/search?q=vercel+pricing&restrict_sr=on&include_over_18=on) (e.g. you must have an enterprise plan if you have >10 team members which is [hidden in the fine print](https://vercel.com/docs/limits/overview#:~:text=Team%20Members%20per,Custom)),
locks you in with [extremely expensive egress fees](https://gist.github.com/brillout/190bc676879a2a615d0bae031969f0a5),
hard to understand and nearly impossible to predict.
Such pricing is a no-go for large enterprises.

You can self-host Next.js as a Node.js server, for example placed in a Docker container. But it won't work precisely the same way as on Vercel.
Furthermore, self-hosting Next.js as a Serverless or Edge application (i.e. replacing Vercel) is worse.

An illustration of the problem: with Next.js server actions you no longer handwrite API endpoints - which means [you don't have the ability to explicitly control versioning](https://twitter.com/thdxr/status/1718308244383228124). So requests from old clients can fail. Vercel solved this with their deployment infrastructure, instead of in Next.js itself. So if you use Next.js but not Vercel then you'll have to deal with this major problem yourself.

These kinds of difficulties led the open source community to develop [Open-Next.js](https://open-next.js.org/), a project to make Serverless deployment of Next.js on generic Functions-as-a-Service (FaaS) platforms easier (specifically on AWS Lambda). It allows easier integration with AWS and reduces Next.js's ties to Vercel. But that is a moving target with things breaking frequently, [according to a person](https://x.com/thdxr/status/1740115107005280592) working closely with the matter.

Edge deployment with Next.js is another story. [Cloudflare](https://blog.cloudflare.com/next-on-pages), the most prominent edge hosting provider, uses its own runtime instead of Node.js. Meaning that some Next.js apps built to run on Node.js won't immediately work on the Edge. So Next.js has an Edge Runtime toolkit/mode that uses only a subset of the Node.js API, but it has [a lot of issues](https://github.com/search?q=repo%3Avercel%2Fnext.js+edge+runtime&type=issues).


### Vike - hosting agnostic

> With Vike, you keep full control over your server and you can use any deployment strategy.

Vike is server and deployment agnostic, which means you can use any hosting provider and any server/serverless setup of choice. Vike is built with Serverless and Edge compatibility from the start.

From a server perspective, <Link text="Vike is just a middleware" href="/deploy" /> that doesn't depend on Node.js and that can run anywhere where JavaScript runs such as AWS, Vercel, Cloudflare, Deno Deploy, or even in the browser.

You can develop apps with a server that doesn't depend on Node.js and deploy it anywhere.

> You can also <Link href="/pre-rendering">pre-render</Link> your app to remove the need for a production server: your app consists only of static assets (HTML, JS, CSS, images, ...) that can be deployed to any static host such as GitHub Pages.

> You do need Node.js for local development, as the development runtime of [Vite (the dev- and build-toolkit used by Vike)](https://vitejs.dev/) depends on Node.js. But Vite's runtime isn't needed in production. Consequently, since Vike's runtime doesn't depend on Node.js, there are no dependencies on Node.js in production.

To integrate Vike, you simply add Vike's middleware to your server (Express.js, Fastify, Edge Worker, Serverless Function, etc.).

With Vike, you have full control over your server and over your deployment strategy, two critical aspects of your business.



## Minimal and self-contained (no deps)

[All dependencies](https://github.com/vikejs/vike/blob/3d042da/vike/package.json#L15-L26) are either shared with Vite (e.g. [`fast-glob`](https://github.com/mrmlnc/fast-glob)) or fully owned (e.g. we own [`@brillout/json-serializer`](https://github.com/brillout/json-serializer)). Adding Vike to your Vite app doesn't add any frivolous dependency.

We believe Vike hits the sweet spot of being a full-fledged frontend tool while avoiding unnecessary bells and whistles.



## Caching

### Next.js - caches by default, must opt-out

Next.js aggressively uses [caching](https://nextjs.org/docs/app/building-your-application/caching), for performance and cost-saving reasons. Less server load means your app uses less compute resources, which saves you money on Vercel's paid plans, but saves Vercel money on their free tier (which most developers will be on; Vercel's long-tail).

Next.js leans towards making as many routes as possible statically rendered (SSG over SSR wherever possible). Caching is enabled by default (both on the server and the client), and you have to **explicitly opt-out** to disable it (using more or less hacky solutions) each time you don't want it.

But people are [finding](https://www.reddit.com/r/nextjs/comments/18tkmdb/has_anyone_abandoned_nextjs_after_using_it_on_a/kffjox2/) the aggressive [caching to be a nightmare](https://www.reddit.com/r/nextjs/comments/18tkmdb/has_anyone_abandoned_nextjs_after_using_it_on_a/kfh6nh2/), and hard to disable. Caching can give a wrong/stale view of your app, and cost precious development time hunting for the cause.

As the saying goes, _"There are only two hard things in Computer Science: cache invalidation and naming things."_ -- Phil Karlton

### Vike - opt-in caching

Vike does not cache, by design, so by default your app will behave as you expect. If you do want caching, you can opt into it by using one of the many industry-standard caching tools.



## Server vs. client workloads

### Next.js - server-first oriented

Next.js - made by Vercel, a hosting provider - is server-focused. It now defaults to interpreting all React components in the React render tree as React Server Components (RSC), and if you don't want that, you have to opt-out. 

With RSCs, you have to inject the bundler directive "use client" (aka. start client bundling) into your React component tree at the start of every branch with components that you want to turn into Client Components.

The default server orientation makes sense for _websites_ that consist of large static sections with no client interactivity. Using RSCs reduce the size of client-side bundles (and hydration), due to the JS code in RSC's only running on the server (e.g. useful for a static site using a heavy markdown library). But RSC's carry serialization and parsing overhead, has special rules (no state, context, or effects), and conceptual overhead that many developers struggle with.

In addition, with Next.js new App Router, there's been a long standing open issue that you [can't render dynamic routes in the app when it is exported to static assets](https://github.com/vercel/next.js/discussions/64660). This is the so called SPA-only mode (render everything only on the client; often used for PWAs), which means you could serving your app from a CDN, and thus obviating the need any server compute.

In all, the fact that Next.js leans more on the server (and RSC's and caching by default) may not be what you want, especially if you are building a _webapp_ which you expect will become more and more dynamic and interactive anyway.

### Vike - granular work-split between server and client

If your product either should be:

- leaning more towards being an _app_ than a _site/page_.
- having a lot of dynamically generated and/or frequently updating content (coming from a DB), where caching doesn't give a lot of gains.
- having a [single unified model for data loading](https://x.com/DevtoolsFM/status/1756091319632683073) that may include polling and [live UI updates](https://www.flightcontrol.dev/blog/nextjs-app-router-migration-the-good-bad-and-ugly#bad-have-to-add-client-side-fetching-for-live-ui-updates).
- local/offline-first, and/or a [PWA](https://web.dev/learn/pwa/assets-and-data#platform-specific_apps_vs_pwa).
- cross-platform (reusing code between web and native), since native platforms are typically client-centered (and it [isn't prioritized](https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#what-does-it-mean-for-react-native) or very clear how React Server Components would work on React Native).
- using less server resources (scalability, cost-wise), in favor of requiring slightly more processing power on the client. Like using a SPA-only mode (static export, to serve from CDN, with no server compute needed), which is often a favored approach for PWAs.

then the server-first orientation of Next.js and Vercel isn't helpful and can be a hindrance.

With Vike, you can choose setups that fit the aforementioned use cases.
You can partially or completely opt out of SSR (turn on/off for whole app, <Link href="/ssr">for some pages</Link>, or <Link href="/clientOnly">for some components</Link>).
You can also use SSR for the first page and then, from there on, use client-only navigation while fetching data directly from the data source (without involving your SSR server).

Vike has first-class support for leaning towards the client-side, as well as first-class support for SSR use cases.
Vike is made by the community and has no incentive to favor any side of the work-split between the client and the server.


## UI Framework agnostic

Next.js is deeply tied to React. So if you want to move to another UI framework later, like for instance [SolidJS](https://www.solidjs.com/), then it means a laborious refactor away from NextJS.
But with Vike, you keep your options open, and can swap out your UI framework rather easily with various <Link text="UI extensions for Vike" href="/extensions" />.

> Vike is completely agnostic to React and its source code has zero dependency on React. You can actually use Vike with any other UI Framework (Vue, Preact, Solid, etc.).
>
> With Vike, you implement and fully control the React integration, which has many benefits. For example, you can use Relay in the same way that Facebook does (with a render-as-you-fetch stream) which isn't possible with Next.js.

With Vike, you can integrate React yourself. This means you need to write a little bit more boilerplate, but in exchange you get a lot more flexibility.
You can even use [vike-react](https://vike.dev/react) to do it for you, and later when you need more control you can eject.
If you want to switch UI framework to Solid, then you can swap vike-react with [vike-solid](https://github.com/vikejs/vike-solid).

Because you can control the React integration, you also have full control over the frontend integration of your favorite tools (data fetching, state management, authentication, etc.).

For example, you can use Relay and Apollo in ways that aren't possible with Next.js.

> Relay is a state-of-the-art GraphQL client developed and used at scale by Facebook (which invented GraphQL). The [YouTube video "Re-introducing Relay"](https://www.youtube.com/watch?v=lhVGdErZuN4) explains in detail the benefits of Relay.
>
> Many users and sponsors leverage Vike's flexibility to integrate Relay with SSR Streaming.

Vike includes everything you'd expect from a frontend framework: Client-side Routing, HMR, Filesystem Routing, Pre-rendering (SSG), Data Fetching, Code Splitting, Layouts, i18n, etc.


## Custom integrations

As depicted above, Vike's philosophy is that you can integrate tools yourself instead of being locked into decisions made by your framework. Use any tool you want, however you want.


## React Server Components

React 18 introduced novel techniques that unlock many capabilities.

Vike, and in particular <Link href="/vike-react">`vike-react`</Link>, extensively leverages React's 18 new techniques. (<Link href="/streaming">Streaming</Link>, <Link href="/streaming#progressive-rendering">Progressive Rendering</Link>, independent and collocated data fetching, <Link href="/RPC">RPC</Link>, etc.)

Vike provides you with extensive control for integrating tools as you see fit, such as control over React's SSR <Link href="/streaming">stream</Link>. At the same time <a href="/extensions">Vike extensions</a> provide built-in integrations for a quick start. We call this dual approach <Link href="/optional-control">optional control</Link>.

One aspect `vike-react` doesn't support yet are components that are loaded only on the server-side. While we are researching a DX for such components, we believe this new paradigm is too early for being used in production. See <Link href="/react#react-server-components" doNotInferSectionTitle />.


## Build your own framework

Vike is designed from the ground up to enable users to build frameworks on top of Vike.

You can build your own framework with only hundreds of lines of code.

> While there are many [uses cases for building your own framework](https://vike.land), the most prominent one is [building company internal frameworks](https://vike.land#scale).

We foster the proliferation of React frameworks, highly-tailored to specific use cases.

Read more at [Vike.land](https://vike.land).
